1. Statement of the Technical Field
The present invention relates to the field of Web services, and more particularly to the cloning and instantiation of Web service instances.
2. Description of the Related Art
Web services have become the rage of distributed computing and are viewed as the foundation for developing a truly universal model for supporting the rapid development of component-based applications over the World Wide Web. Web services are known in the art to include a stack of emerging standards that describe a service-oriented, component-based application architecture. Specifically, Web services are loosely coupled, reusable software components that semantically encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols.
Conceptually, Web services represent a model in which discrete tasks within computing processes are distributed widely throughout a value net. Notably, many industry experts consider the service-oriented Web services initiative to be the next evolutionary phase of the Internet. Typically, Web services can be defined by an interface such as the Web services definition language (WSDL), and can be implemented according to the interface, though the implementation details matter little so long as the implementation conforms to the Web services interface. Once a Web service has been implemented according to a corresponding interface, the implementation can be registered with a Web services registry, such as Universal Description, Discover and Integration (UDDI), as is well known in the art. Upon registration, the Web service can be accessed by a service requestor through the use of any supporting messaging protocol, including for example, the simple object access protocol (SOAP).
In a service-oriented application environment supporting Web services, locating reliable services and integrating those reliable services dynamically in realtime to meet the objectives of an application has proven problematic. While registries, directories and discovery protocols provide a base structure for implementing service detection and service-to-service interconnection logic, registries, directories, and discovery protocols alone on occasion are not suitable for distributed interoperability. Rather, a more structured, formalized mechanism can be necessary to facilitate the distribution of Web services in the formation of a unified application.
Notably, the physiology of a grid mechanism through the Open Grid Services Architecture (OGSA) can provide protocols both in discovery and also in binding of Web services, hereinafter referred to as “grid services”, across distributed systems in a manner which would otherwise not be possible through the exclusive use of registries, directories and discovery protocols. As described both in Ian Foster, Carl Kesselman, and Steven Tuecke, The Anatomy of the Grid, Intl J. Supercomputer Applications (2001), and also in Ian Foster, Carl Kesselman, Jeffrey M. Nick and Steven Tuecke, The Physiology of the Grid, Globus.org (Jun. 22, 2002), a grid mechanism can provide distributed computing infrastructure through which grid services instances can be created, named and discovered by requesting clients.
Grid services extend mere Web services by providing enhanced resource sharing and scheduling support, support for long-lived state commonly required by sophisticated distributed applications, as well as support for inter-enterprise collaborations. Moreover, while Web services alone address discovery and invocation of persistent services, grid services support transient service instances which can be created and destroyed dynamically. Notable benefits of using grid services can include a reduced cost of ownership of information technology due to the more efficient utilization of computing resources, and an improvement in the ease of integrating various computing components. Thus, the grid mechanism, and in particular, a grid mechanism which conforms to the OGSA, can implement a service-oriented architecture through which a basis for distributed system integration can be provided—even across organizational domains.
In a grid architecture, a factory service can be provided which can be tasked with the responsibility for creating and deploying new instances of Web applications. Typically, a Web application in the context of Web services technology can include a collection of servlets, server pages, markup language documents, and supporting elements such as images. The collection can be packaged in an archive so that the Web application can be portably deployed to any servlet-enabled Web server. In a conventional Web application archive, the Web application can be packaged as follows:    index.html    example.jsp    images/on.gif    images/off.gif    WEB-INF/web.xml    WEB-INF/lib/example.jar    WEB-INF/classes/MyServlet.class    WEB-INF/classes/com/servlet/MyWebServlet.class    etc.Once packaged, the archive can be deployed to an application server.
Notably, in a conventional implementation, the “WEB-INF” directory can be considered to be ‘special’ as anything stored under the WEB-INF directory is not to be served directly to clients. Rather, the WEB-INF directory typically contains class files used by servlets, for instance, and configuration information used by the Web application itself. In that regard, the web.xml file residing in the WEB-INF directory often is referred to as the ‘deployment descriptor’. The deployment descriptor can contain detailed information about the Web application such as URL mappings, servlet registration details, welcome files, MIME types, page-level security constraints and the like.
While cloning a Web application in a static, local manner is a well-understood process, cloning a Web application in a dynamic, remote manner is not so well-understood. Yet, remotely cloning and instantiating a Web service can be critical process in the grid context for enabling Web service invocation capacity to be dynamically increased during peak utilization periods, such as in the case of a retail shopping application which operates during the peak, holiday shopping season. Moreover, remotely cloning and instantiating a Web service can be critical for leveraging large scale grid computing environments in an autonomic fashion.
The artisan of ordinary skill might presume that remotely deploying and instantiating a Web service might involve little more than compressing the archive file containing the Web application, and transmitting the compressed archive to a target, remote enterprise service. Still, in practice, the remote cloning and instantiation of a Web service can be substantially more complex. Specifically, several deployment issues first must be addressed. More particularly, as it will be recognized by one skilled in the art, any WSDL document that exists for the cloned Web service will not have the correct location bindings for the hosting server. Thus, it will be necessary to generate new WSDLs for each new Web service instance.
Also, while a new WSDL implementation document usually will be required, in some cases an existing WSDL interface document can be re-used. Additionally, when creating a new Web service instance on a remote server, it is possible that concurrently, another factory create operation might clone and instantiate an instance of the same Web application to the same remote host. As both cloning operations will involve identical copies of the deployment descriptor, it is important to ensure that two separate Web service instances are deployed notwithstanding the presence of the identical deployment descriptors.
Notably, in some circumstances, different Web service instances can involve the same Web application and, as a result, the different Web service instances can share common library resources. As it will be understood by one of ordinary skill in the art, sharing common library resources can provide a tremendous benefit with regard to reducing the amount of computing resources—namely memory, ordinarily associated with the instantiation and operation of a Web service instance. Yet, in other circumstances, each Web service instance might require a separate Web application due to special needs, such as a required specific version of a supporting library, for example an XML parser. Finally, in order for remote Web service cloning and instantiation to become a viable technology, security mechanisms must be employed.